The utilization of web applications using a web browser as the caller is rapidly expanding in many areas of use, from on-line shopping sites to the business systems of corporations. Today's web applications use a component-based structure combining a plurality of small-scale software components with a view to facilitating quick development and flexible functional modification. As platform techniques for such component applications, there are J2EE (Java 2 Enterprise Edition) (Java is a registered trademark of Sun Microsystems, Inc.) and .NET (registered trademark of Microsoft Corporation). The usual practice is to develop web applications by using one or both of J2EE and .NET. J2EE and .NET provide APIs (Application Programming Interfaces) for web applications, and the developers of web applications develop web applications by using these APIs. Web applications developed by using these APIs are executed on a platform for executing applications known as a J2EE server or a NET server. In the following paragraphs, component applications and a platform for their execution will be described, with J2EE taken up as an example.
Components in J2EE are referred to as EJBs (Enterprise Java Beans). Main EJBs include a session bean and an entity bean. The session bean is an EJB, which performs processing correspondingly to the user's session, while the entity bean is an EJB representing permanent data irrespective of the user's session. Entity bean data are usually stored in a database. EJBs are components stated in the Java language in accordance with the API of J2EE. An EJB supports two interfaces including a remote interface and a local interface to refer to itself from outside, such as another EJB. The remote interface is mainly used for calling the EJB deployed on a remote machine. On the other hand, the local interface is used for communication with a local EJB deployed on the same J2EE server. Which of the two interfaces can be used depends on the packaging of the EJB.
The configuration of a platform for execution of component software according to a known technique is shown in FIG. 2, with the J2EE server taken up as an example. Reference numeral 100 denotes an execution platform for component-based software; 110, a deployer; 300 and 320, containers each of which is an execution environment for EJB execution; 310 and 330, remote request receivers for receiving requests between containers; 311, a remote request sender for sending requests between containers; and 400, a name server. Reference numeral 200 denotes a file system, in which EJB class files 210 and 211 are to be arranged. In the example shown in FIG. 2, two files EJB A and EJB B are deployed in the J2EE server. Incidentally, though only one application execution platform is shown in this drawing, it is also possible to architect one application by making ready a plurality of application execution platforms and distributively deploying an EJB on each platform. The constituent elements shown in FIG. 2 will be described below.
The name server 400 is a server that manages the bindings between names and objects and supports functions of JNDI (Java Naming and Director Interface) APIs. The name server 400 has a table 401 and a name server controller 402. The table 401 has fields of names 411 and objects 412. The name server controller 402 provides JNDI APIs to the caller and realizes the functions of each API. The name server has the following four APIs.    (1) bind    (2) lookup    (3) rebind    (4) unbind
Of these APIs, “bind” registers pairs of a name N and an object O (N, O) each in the name server 400; “lookup” references the name server 400 by the name N and takes out the object O matching the name N; “rebind” changes the object part of the name N-object O pair (N, O) from O to On; and “unbind” removes the entry (N, O) of a name N from the name server. Two entries 421 and 422 are registered in the table 401 of the name server 400 of FIG. 2. Although the name server 400 is present in the application execution platform shown in FIG. 2, name server 400 may be present independent of the application execution platform.
The deployer 110 reads in EJBs from the file system and creates containers for the EJBs and remote request sender and receivers on that basis, referred to as deploying. When EJB A is to be deployed for instance, the deployer 110 reads in the class file 210 of EJB A from the file system 200, and creates the container 300, the remote A request receiver 310, and the remote A request sender 311 of EJB A. Then deployer 110 calls the “bind” API of the name server 400 and registers the pair of the name A of EJB A and remote interface IntConA of the container 300 (A, IntConA) in the name server 400 denoting the registered entry as 421. When EJB B is deployed in the same way, the deployer 110 reads in the class file 211 of EJB B from the file system 200, and creates the container 320, the remote B request receiver 330 and the remote B request sender (the remote B request sender will not be used hereinafter and accordingly is not shown in FIG. 2) of EJB B. Then deployer 110 calls the “bind” API of the name server 400 and registers the pair of the name of the component B and the remote interface IntConB of the container 320 (B, IntConB) in the name server 400 denoting the entry as 422.
The deployer has a function to undeploy any deployed EJB. To undeploy an EJB, first an EJB instance operating on the container of the EJB is discarded, and then the container, remote request receivers, and remote request sender are discarded.
The container 300 and the container 320 are execution environments for supporting the execution of an instance 301 of EJB A and an instance 321 of EJB B, respectively. The instances 301 and 321 are created in accordance with a “create” request from the caller.
The remote A request receiver 310 and the remote A request sender 311 are paired, and support communication for remote requests of EJB A from the caller. Similarly, the remote B request receiver 330 and the remote B request sender (not shown in FIG. 2) are paired, and support communication for remote requests of EJB B from the caller. The protocol of RMI (remote method invocation)-IIOP or the like is generally used for these communication processes. The remote request receivers (310 and 330) may constitute the skeleton of RMI, and the remote request sender (311), the stub of RMI. These pairs of remote request receivers and remote request senders are either automatically created by the J2EE server at the time of deploy or incorporation into the J2EE server from the outset.
The file system 200 is a file system of the OS by which the execution platform of component-based software 100 operates.
The class files 210 and 211 are object files of Java, and are obtained by compiling Java source codes with a Java compiler. Or these class filed consist of object files obtained by compilation and deployment descriptors for their deploying, archived as JAR files.
The description of a method call between EJBs with reference to a case in which the instance 321 of EJB B calls a method “methodX” of EJB A in FIG. 2. The codes for calling the method “methodX” of EJB A in EJB B are generally stated as shown in FIG. 3. First on the first and second rows of FIG. 3, the name server 400 is referenced by using the “lookup” API of JNDI, and the remote interface of the container A of EJB A matching the name A is acquired, the “home interface”. Next on the third row, the “create” method of the home interface of EJB A is called. The call for the method “create” of the remote home interface reaches the container A 300 via the container B 320, the remote A request sender 311, and the remote A request receiver 310. The container A 300, upon receiving the create request, creates one instance 301 of EJB A, and returns the remote interface of this instance 301 of EJB A, the “component interface”, as the return value to the instance 321 of EJB B via the remote A request receiver 310, the remote A request sender 311, and the container B 320. The component interface is received by the instance 321 of EJB B. Finally, when the instance 321 of EJB B calls on the fourth row the method “methodX” to the component interface of EJB A, that request reaches the instance 301 of EJB A via the container B320, the remote A request sender 311, the remote A request receiver 310, and the container A 300. The called instance 301 of EJB A executes the method “methodX”, and returns the result to the instance 321 of EJB B via the container A 300, the remote A request receiver 310, the remote A request sender 311, and the container B 320.
For the purposes of the present discussion, it was assumed that when EJB B is the caller of EJB A and is to communicate with the container A 300 by using the home interface of EJB A, EJB B communicates with the instance 301 of EJB A by using the component interface, the same remote request sender 311 and remote request receiver 310 would be used. The message for a remote request passing the remote request sender and the remote request receiver in order to realize such communication is composed as represented by 1100 in FIG. 17, wherein reference numeral 1101 denotes a target identifier indicating the target of access; 1102, the method to be called; and 1103, the list of method arguments of the method 1102. The target identifier is a container ID or an EJB instance ID. The remote request receiver (310 or 330) executes a request, when the target identifier 1101 of the message 1100 is a container ID, to the container or when it is an EJB instance ID, to the EJB instance. Depending on the packaging of the J2EE server, two types of remote request senders and remote request receivers may be used, one for the home interface and the other for the component interface.
While the foregoing description referred to a case in which an EJB provides a remote interface, where a local interface is to be provided, local receivers and local senders may as well be used in place of the remote request receivers and the remote request to make possible optimized low-cost communication, specialized for use within the same J2EE server.
Now, with the dissemination of such web application sites, competition among these sites is intensifying, and every site is pressed for quick modification and addition of functions to match customers' preferences. Quick modification and addition of functions requires development and testing within a limited period of time, and therefore adequate testing cannot always be done. Therefore, bugs are highly likely to remain in a web application already being operated, and such bugs may invite failures and stop the service. These bugs may invite failures in the system, and in the worst-case stop its service. Since the system failure of a web application caused by bugs or any other reason would inflict an enormous loss on the site, interest is now focused on methods of execution that can keep the website in service, even in the presence of bugs.
As is known to those possessing an ordinary skill in the pertinent arts, restarting the application can tentatively solve many of the failures invited by bugs, some of the sites operating web applications periodically restart their web applications to prevent failures.
Methods of efficient restoration from failures by implementing restarting at the level of components of fine grain size are disclosed in JP-A No. 82926/2002 (Patent document 1) and George Candea, et al., “A Microrebootable System—A Technique for Cheap Recovery, 6th Symposium on Operating Systems Design & Implementation 2004 (Non-patent document 1).
Patent document 1 discloses a remedial method for use in a component-based application by which codes for measuring the processing time are embedded into software components to monitor the reliability and performance of the system during its execution, the processing time is thereby measured, the components are determined to be in an abnormal state, if the measured processing time exceeds a preset threshold, and the components are blocked or restarted.
Non-patent document 1 discloses a technique known as microrebooting by which faster restoration from a failure is achieved as compared to restarting the whole application. This timesaving can be achieved by restarting only the failed component in which bugs or any other trouble has occurred, out of the components constituting the web application. This document also describes a method by which, if there is a sign of imminent failure, the likely failure is prevented at low cost by microrebooting the components.
On the other hand, restarting involves a problem that a processing request addressed to the restarted component would result in an error. As proposed solutions to this problem, JP-A No. 77120/1996 and JP-A No. 290637/2001 (respectively Patent documents 2 and 3) describe methods by which a new component is created in advance, instead of ending and restarting an existing component, and restoration from failure and prevention of error can be achieved at the same time by replacing the old component with the new.
According to Patent document 2, a monitoring process is allocated to each of the objects and instances constituting the application and monitors the status of execution of every object and instance, and any object or instance diagnosed to be abnormal is replaced with a substitute object or instance.
Patent document 3 discloses a method of replacing, in a multi-process multi-thread application, some components with new ones without stopping the application. By this method, all the processing threads for the components to be replaced are stopped temporarily, and the components are replaced when all the threads have been stopped.
However, these conventional techniques involve the following problems. First, there is a problem of deterioration in performance because, when any component is to be replaced, the whole processing on that component is stopped. Second, when the method of an EJB is to be called, as described above, the calling party successively acquires the home interface and the component interface of the EJB to be called, and finally makes the intended request. Any request to the EJB subsequent to the replacement of the call destination EJB should be executed on the new EJB having replaced the old one. However, if the call destination EJB is replaced immediately after the calling side has acquired the home interface or both the home interface and the component interface, any subsequent request will be attempted to be executed on the old EJB because the interface is that of the old EJB. If the old component is ended immediately after the EJB replacement, any request to that old EJB will end up as an error. A method which allows the old component to survive the EJB is conceivable, but since the home interface and the component interface for the old EJB may be kept alive by the caller's program for a long time, the attempt to prevent failure by replacing the EJB may fail, because the old component may not be completely ended and this might invite a failure.
Then, a first problem to be solved by the present invention is to provide a method for executing a component application to replace components adaptively to any sign of an imminent failure or the actual occurrence of a failure, which is a technique for component replacement which allows no error or no deterioration in performance to occur at the time of replacing components. A second problem to be solved by the invention is that of the interfaces posing a difficulty in component replacement.